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W hile recently consulting for a client, I developed 

a miniframework that incorporated several design 
patterns. These patterns combined to make a 
rat her co m p I ex h i erarc hy of su bty pes act I i ke a si n gl e cl ass. 
Besides providing useful functionality that the client and 
their customers needed (which never hurts!), the frame¬ 
work successfully demonstrated the following techniques: 
• what I call "how to do a case statement in Smalltalk," 
the Objects from States pattern 1 
•an example of the Reusability through Self- 
Encapsulation pattern language 2 
• a variation of the Factory Method pattern 3 
•an exampleof what I call the "Null Object" pattern, 
also known as NoWorker 4 and Null Representation 5 
•limited amounts of visual behavior in domain objects 
The framework itself is an example of a case statement 
using Self-Encapsulation. In it are a set of Factory Meth¬ 
ods and a Null Object. Even though it is a framework of 
domain objects, it still contains some application model 
behavior used to display the objects in a view. Not only 
does the framework show simple examples of these pat¬ 
terns, but it also shows how to combine individual pat¬ 
terns together to solve more complex problems. 

THE PROBLEM 

Part of th i s cl i en t's system con si sted of a questi on n ai re the 
user could display so that he could answer it. Analysis 
revealed that the domain objects were Questionnaire, 
which contained a list of Questions, each of which had 
exactly one Answer. Further requirements gathering dis¬ 
covered that there were three different ways a user could 
answer a question: most questions needed yes/no 
answers; some needed one of a list of possible answers; 
others needed freeform text answers. The view could eas¬ 
ily i ndicate these different ways of answeri ng usi ng check 
boxes, combo boxes, and input field widgets, respectively. 

Most of the domain code had already been imple¬ 
mented fo r me. T h ere were a I ready Qu est i o n n a i re, Qu est i o n, 
and Answer classes, and the container relationships 
between the three had been defined. The problem was 
the difficulty supporting the three different ways of 
answering and the three different kinds of visual widgets 
used to input and display answers. 

The solution that had been implemented required a 
lot of fairly ugly code in the Answer class. The class had 


three instance variables: yesOrNo, selection, and 
responseText. Each instance only used one of those vari¬ 
ables; the other two were always nil. The displaystring 
method printed-out each variable's value as long as it 
wasn't nil; because only one variable was not nil at any 
given ti me, that's the only one that was pri nted. What the 
implementation did not solve was displaying a particular 
Answer as different widgets. When I started on the project, 
testing methods like isYesNo, isSelection, and isText were 
about to be introduced. 

SMALLTALK CASE STATEMENT 

Obviously Answer was becoming too complex. The solu¬ 
tion I devised was to expand the Answer class into a hier¬ 
archy of classes: 

Answer () 

BooleanAnswer (yesOrNo) 

EnumerationAnswer (responseChoices, responselndex) 
TextAnswer (responseText) 

This way each question could have the appropriate type 
of answer: boolean, symbol, or text. None of the Answer 
objects wasted any instance variables. Each class knew 
what its instance variables' types were and how to han¬ 
dle them. This factored the complexity of handling 
these different possibilities into separate classes so that 
the decisions each class had to make were actually quite 
simple. 

The reason I call this hierarchy an exampleof a Small¬ 
talk case statement is that it eliminates the need for test¬ 
ing methods like isYesNo, isSelection, and isText. An ex¬ 
ample of a case statement method would be something 
like 

Answer»visualWidget 

self isYesNo ifTrue: ["Use a check box."], 
self isSelection ifTrue: ["Use a combo box."], 
self isText ifTrue: ["Use an input field."]. 

This is poor object-oriented (O-O) style. Sometimes de¬ 
velopers clamor for Smalltalk to have a case statement, 
usually because they're trying to write code like this. 
Although all of uswrite codelike this sometimes, it isbest 
avoided. Factoring the class into a hierarchy allowed me 
to eliminate the testing methods and simplify the code 
likethis: 
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Answer»visual Widget 

'"self subclassResponsibility 

Boolean Answer»visualWidget 
"Use a check box." 

EnumerationAnswer»visualWidget 
"Use a combo box." 

TextAnswer»visualWidget 
"Use an input field." 

This is a case statement via polymorphism and inheri¬ 
tance. Just send the message and whatever implementer 
gets run is the correct case. This forces the "testing” to be 
encapsulated within the hierarchy where it can easily be 
reused. If the results of the testing need to be changed, the 
code is easier to maintain because it is so cleanly encapsu¬ 
lated. Finally, the differences between the peer classes are 
easy to see; just look at the methods they implement 
instead of inheriting. 

This case statement framework is also easy to extend to 
add new cases. For an example of this, see the "Null 
Object" section of this article. 

SELF-ENCAPSULATION 

A problem this hierarchy introduced is that now each 
particular Question instance had to know what kind of 
Answer instance it had. To avoid this problem, I wanted 
all of the concrete classes to be polymorphically equiva¬ 
lent. Thismeans that they would all have the same com¬ 
mon interface so that I could generally treat any 
instance as an Answer without regard to which concrete 
subclass it was. 

To do this, I defined the common interface in Answer 
with messageslike response, response:, and displaystring. In 
Answer, each of these methods returned the subclass¬ 
Responsibility error. Each subclass implemented the mes¬ 
sages appropriately in terms of its state. For example, 
here’s how EnumerationAnswer handled the response aspect: 

EnumerationAnswer»response 
| index | 

index : = self responselndex. 

"Index == 0 
ifTrue: [nil] 

ifFalse: [self responseChoices at: index] 

EnumerationAnswer»response: newResponse 
self responselndex: 

(self responseChoices 

identitylndexOf: newResponse) 

This is an exampleof the Reusability through Self-Encap¬ 
sulation pattern language, albeit an extremely simple ex¬ 
ample. The language shows how to implement an ex¬ 
tensible yet well-encapsulated hierarchy. An abstract 
su percl ass defi nes the i nterface the su bcl asses wi 11 fol low. 
The interface is implemented i n terms of a smal I number 
of kernel methods that each subclass must implement 
appropriately. As the language suggests, Answer defines 
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the hierarchy’s interface and leaves the implementation 
details to the subclasses. 

This could be considered a variation of the Factor a 
Superclass pattern. 6 That pattern starts with a number of 
peer classes and factors their shared variables and behav¬ 
ior i nto a common superclass so that the subclasses do not 
duplicate each other’s variables and behavior. What I did 
with Answer was the same process i n reverse; I started with 
one class and factored it into many subclasses. I use the 
superclass to define a common interface rather than 
implement common behavior, so my efforts are more rem- 
i n i scent of Self- Encapsu I ati on than Factor a Su percl ass. 

FACTORY METHOD 

Another problem the Answer hierarchy introduced is the 
matter of assuring that the right ki nd of Answer i nstance gets 
assigned to each Question. Flow does a Question phrased asa 
yes/no question get a BooleanAnswer? Flow does one with a 
list of possible answers specify that it needs not only an 
EnumerationAnswer but the list of choices as well? 

To solve this problem, I introduced the following mes¬ 
sages into Question: useYesNoAnswer, usePossibleAnswers:, 
and useTextAnswer. This way, as each Question was created, 
the answer details could be specified as well. Flere are 
some examples: 

questionl := (Question text: 'Do chickens have lips?') 

useYesNoAnswer. 

question2 := (Question text: 'Are you lazy?') 

usePossi bleAnswers: 

#(#always #sometimes #never). 

question3 := (Question text: 'Flow old are you?') 

useTextAnswer. 

I wanted to hide the complexity of the Answer hierarchy 
and maintain the illusion that it was still just one class. 
This way the one class could actually manage the other 
classes and their use. This will also encapsulate this 
management within the class. Because this is not a com¬ 
plicated hierarchy, its management is fairly simple. 
Answer's instance creation protocol just has to allow for 
creating each kind of answer. Flere are the methods that 
do this: 

Answer class»yesNoAnswer 
"'BooleanAnswer new 

Answer class»possibleAnswers: answerList 

"'EnumerationAnswer new responseChoices: answerList 

Answer class»textAnswer 
"TextAnswer new 

Question in turn just delegates the Answer creation to that 
class: 

Question»useYesNoAnswer 

self answer: Answer yesNoAnswer 

Question»usePossibleAnswers: answerList 
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self answer: (Answer possibleAnswers: answerList) 

Question»useTextAnswer 

self answer: Answer textAnswer 

The three instance creation methods in Answer are exam¬ 
ples of the Factory M ethod pattern, or at least a variation 
thereof. Gamma et al. say that the "Factory M ethod lets a 
class defer instantiation to subclasses." A classic example 
in Smalltalk-80 is the way View defines the method 
defauItControllerClass. Each subclass of View subimple¬ 
ments defaultControl lerClass to return the class for its con¬ 
troller. Thus defau ItControllerClass is a Factory Method. 

The Factory Methods in Answer are yesNoAnswer, 
possi bleAnswers:, and textAnswer. Because they are not 
standard protocol that is overridden in subclasses, they 
are not standard Factory Method examples. However, 
they are a variation on the same theme because they use 
message sends to hide the existence of the various Answer 
subclasses, as well as their names and i nterfaces. As far as 
a collaborator I ike Question is concerned, there is only one 
Answer class (not a hierarchy) and it isableto act in these 
various ways This encapsulates the hierarchy and si mpl i- 
fies its i nterface to the rest of the system. 

I cannotclaimto have invented thistechnique. InVisu- 
alWorks, Filename uses it to determine which of its sub¬ 
classes to use. Similarly, CompositePart uses it to determine 
which Wrapper class to use. 

Alternate solution: Question hierarchy 

When analyzing the requirements and designing a so¬ 
lution,! considered developing a Question hierarchy as well 
as an Answer hierarchy. This would have incorporated 
Factory M ethod more di rectly by usi ng subclassi ng (as the 
pattern suggests). The Question class would have defined 
a method like defaultAnswer in terms of defauItAnswerClass. 
Then Question subclasses would overridedefaultAnswerClass 
to return theappropriateAnswer subclass. 

For example: 

Question»defaultAnswer 
'"self defau ItAnswerClass new 

Qu est i o n »d ef a u ItAnswerClass 
''Answer 

BooleanQuestion»defaultAnswerClass 

''BooleanAnswer 

and so forth for EnumerationQuestion»defauItAnswerClass 
and TextQuestion»defauItAnswerClass. In fact, I did imple- 
mentQuestion»defaultAnswerClass in preparation for such 
a protocol. 

This combining of dual hierarchies is an example of 
the Bridge pattern, where an abstraction is decoupled 
from its implementation by implementing it in two hier¬ 
archies. The two hierarchies can be extended indepen¬ 
dently, and because they are connected by a standard 
interface, most any pair of instances from the two hierar¬ 
chies can work together. 3 


The problem with Question and Answer hierarchies is 
that the classes are not decoupled from each other. There 
is a one-to-one correspondence between the classes in 
the two hierarchies: BooleanQuestion/BooleanAnswer, 
EnumerationQuestion/EnumerationAnswer, and TextQues- 
tion/TextAnswer. Anytime a new class was added to one 
hierarchy, a corresponding classjust like it would need to 
be added to the other hierarchy, eg., RangeQuestion would 
require SliderAnswer. So these hierarchies are not truly 
decoupled; in fact, they requireduplicate effort to extend 
both hierarchies. 

Another problem with the Question hierarchy is that 
subclasses would not have behaved differently from their 
superclass. All Questions were essentially the same, even 
though they expected different types of answers. 
Hopefully, those that claimed to need a yes/no answer 
were phrased as a yes/ no question, but there was no way 
to enforce this in BooleanQuestion. 

I n the end, although an Answer hierarchy looked prom- 
ising, a similar Question hierarchy not only wasn’t helpful, 
but was in fact counterproductive. The Question subclass¬ 
es would not have introduced any helpful behavior but 
would have required duplicate effort. Thus a Question 
hierarchy was not necessary. 

Tangent topic: SelectionState class? 

Kent Beck recently wrote an excellent column, "Clean 
code: Pipe dream or state of mind?” 7 In it, he describes 
how he factored out a State Object using two classes, 
SingleSelectionState and GroupSelectionState, a terrific solu¬ 
tion to the problem he was facing. He might have taken the 
solution one step further by using the Factory Method 
variation described here. Using it, he would introduce an 
abstract class, SelectionState. 

TheSelectionState class would define the interface for all 
SelectionState instances (SingleSelectionState, Group¬ 
SelectionState, and eventually DelegationSelectionState). It 
would also serve as the hierarchy's interface to the rest of 
the system (collaborators such as SelectionTool). Then 
methods like SelectionTool»setSelectionState: could be 
moved into SelectionState (probably as 
SelectionState»setSelectionState: aFigure). setSelectionState: 
is a fairly messy method that must contai n a lot of knowl¬ 
edge about the classes in the SelectionState hierarchy. 
Notice that when Kent introduced an additional class, 
DelegationSelectionState, he had to rewrite this method. 
This messiness indicates that the method should be 
encapsulated within the hierarchy, which moving it to 
SelectionState would do. Also, if setSelectionState: were ever 
needed by another collaborator that was not a Selection- 
Tool, the method would be available for reuse. 

NULL OBJECT 

Although requirements gathering discovered fairly early 
on that there were three types of answers—yes/ no, list of 
choices, and freeform text—we discovered later that there 
wasactuallyafourth, hidden case to be considered. Some 
"questions" in the questionnaire were actually not ques- 
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tions perse, but headings for subsequent questions. Such 
a question might be "Check each of the following traits 
that describes you:" 

Why not Heading? 

The problem this introduces is that such a heading is 
more of aHeading object than aQuestion object. Both have 
text, but headings don't have answers the way questions 
do. But then how should this be displayed in a view? 

The questionnaire was displayed 
as a table with two main columns, 
question and answer. Every row was 
expected to have two aspects that 
would be displayed in the two 
columns. Thus Heading needed to 

have an answer aspect just like 
Question, and the heading's answer 
would need to be able to display 
itself the way an Answer can. 

This caused Heading to work just 
likea Question, so I found no need for 
a separate Head i ng class. This sol ution 
may be an example of i mproperly let¬ 
ting the view define the domain; iterating over the design 
might produce a better one. Yet I feel that the solution 
described below turned out pretty well and may in fact be 
the most graceful wayto hide the exceptions to someother- 
wisesimpleand uniform rules. 

Perhaps another reason I rolled Heading into the 
Question class is that my deadline for completing this sub¬ 
system was rapidly approaching. It's funny how when I'm 
near a deadline, the current design I've already imple¬ 
mented can look much better than an alternative that 
requires rewriting a lot of code! 

A heading's answer 

Modeling the heading as a Question object, it had to have 
an Answer, but none of the three Answer subclasses 
applied. For this purpose, I developed a fourth Answer 
subclass cal led NullAnswer: 

Answer () 

NullAnswer () 

Asa subclass of Answer, NullAnswer preserved the Answer 
interface, but did so without doing anything. Here are 
some examples of the methods it defi ned: 

NullAnswer»response 

"nil 

NullAnswer»displayString 

"'n/a' 

NullAnswer isan example of what I call theNull Object pat¬ 
tern. I haven't seen documentation for this pattern pub¬ 
lished anywhere, but it is discussed fairly often. The pat¬ 
tern describes an object that shares the same interface as 
others of its type but that reacts to these methods by doi ng 
nothing. The trick is in designing, for each message, what 
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doing nothing means. Typically it means getters that 
return nil or empty collections and display methods that 
show the object as null. Setter methods are usually 
ignored; they can create a real instance and substitute it 
for the Null Object, but this is more the behavior of a 
Proxy 3 than a Null Object. 

The beauty of a N u 11 Object i s that it su pports an exten- 
sive, customized interfaceand encapsulates the decisions 
about how it should "do nothing." nil is perhaps the most 

famous Null Object, but it doesn't 
really count because its interface is 
neither extensive nor customized. 
Yet programmers often use nil in a 
variable that hasn't been assigned 
yet. Th i s I eads to co pi ous amou nts of 
code that constantly check the vari¬ 
able for nil before sending it mes¬ 
sages. This code can be simplified by 
assigning the variable a Null Object 
of the correct type and then sendi ng 
the variable messages with impunity. 
Also, rather than each collaborator 
deciding what to do when the var¬ 
iable is nil, these decisions are encapsulated within the 
Null Object for reuse and consistency across all collabora¬ 
tors. 

Adding NullAnswer 

The infrastructure to support the new NullAnswer class 
was easy to introduce because the hierarchy was well 
encapsulated. It consisted of exactly one method: 

Answer class»nu I lAnswer 
"NullAnswer new 

Then collaborators, such as Question, just needed to tie 
into the expanded interface in a convenient way: 

Questi on »useNul lAnswer 

self answer: Answer nullAnswer 

Other collaborators could tie i n just as easily. 

VISUAL CODE IN DOMAIN OBJ ECTS 

One of the distinguishing factors of the different types of 
answers is the way they were to bedisplayed. Asdescribed 
earlier, a question could be displayed as a check box, a 
combo box, or an input field. Also, a null answer would 
need to bedisplayed with a "do nothing" widget. 

Much has been written recently about the importance 
of separating domain and application behavior, including 
by me. 8 Basically, domain objects represent core business 
behavior, while application objects know how to display 
domain objects in useful ways. This is the basic architec¬ 
ture I follow for all of my development, including the 
Questionnaire framework. 

Questionnaire is the root of the domain framework de¬ 
scribed earlier. In turn, I also implemented a correspond¬ 
ing Questionnairelll class to represent Questionnaires. 
(Because I was developing in VisualWorks, Questionnairelll 


A Null Object supports 
an extensive, customized 

interface while 
encapsulating how to 

"do nothing." 
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was a subclass of ApplicationModel.) Questionnairelll was Finally, I was still able to distinguish the application 
essentially a glorified table sort of widget where each row code from the domain code in this domain class using 
displayed a question.The table had two main columns, the ENVY (ENVY/Developer, Object Technology Internation- 
question text and the question answer. al, Inc.). I defined the Answer hierarchy in the Domain 

application.Then I extended each of the hierarchy's cl ass- 
Why not AnswerUI? es in the Ul application to add the visualWidget method. 

The strength and limitation of this simple design are that This not only clarified which Answer methods were for Ul 

there were no application models for the Questions and behavior, but it also meant that a developer could easily 

their Answers. I did not want these application models unload all Ul code from the image—even that which the 

because the Questionnairelll itself was just a table, practi- domain classes contained—by unloading the Ul 

cally a TableView or a DataSetView (in VisualWorks). Just as application, 

those classes don't contain separate "RowView" and 
"Cel I View" classes, I didn't want Questionnairelll to contain CONCLUSION 

numerous Questionlll objects. Those would do nothing Onesimpleclassin oneminor part of a system turned out 

more than contain QuestionTextUI and AnswerUI objects, to employ a number of powerful 0-0 techniques. Answer 

each of which would do little except to contain a single was conceptually an uncomplicated little class that 

view such asInputFieldView or ComboBoxView. This seemed turned out to have multiple personalities. As the code to 

to me like an explosion of custom classes and do-practi- support those personalities grew, the need to expand the 
cally-nothing objects, a complication I wanted to avoid. class into a hierarchy became apparent. But because the 
Once again, avoiding these classes appears to be the most complexity of the hierarchy distracted from the simplicity 
graceful way to hide complicated exceptions to otherwise of the class, the need to hide this complexity became ap- 
simple, uniform rules. parent as well. I was able to develop this complex hier- 

Had there been an AnswerUI class, it could have made archy with a simple, single class-like interface by using 

the decision as to what kind of widget to use to display and combiningthefollowingtechniques: 
each kind of Answer (its domain model). Actually, this •Smalltalk Case Statement: This is what led to the 

might have necessitated the need for a separate AnswerUI hierarchy. Each case was represented as a separate 

subclassfor each Answer subclass. Then theAnswerUI hier- class. 

archy would have been tightly bound to the Answer hier- • Self-Encapsulation: This is what led to the abstract 
archy and duplicate effort would have been required to superclass. It defined the public interface that ail 

extend both in tandem. In any event, I did not have any subclasses would support so that various instances 

AnswerUI class available. All I had wasacell in atablethat could be treated polymorphically. 

was supposed to display an answer and an Answer domain • FactoryMethodiThishid theconcrete subclasses so that 
object that contained the data for that cell. they were never referenced from outside the hierarchy. 

The hierarchy's collaborators interfaced with the ab- 
How to display an Answer stract superclass, telling it what behavior was expected 

Because the Question sand Answers did not have their own from a new instance and trusting the superclass to 

application model counterparts, there was no obvious return an appro pri ate in stance, 

place to put the code that decided howto display the dif- •Null Object: This substituted as the answer for a 
ferent types of Answers. The way I solved this problem was question that did not need an answer. It supported the 

to havethecell ask the domain object what widget should abstract superclass's interface and thus could be used 

be used to display it. The domain object would return the just like any other concrete subclass. And it encap- 
widgetandthetablewoulddisplaythatwidgetin thecor- sulated the "do nothing" code so that all questions 
responding cell. without answers would behave the same. 

This necessitated introducing the message visualWidget • Visual Code in Domain Objects: This acted as the 
into the Answer hierarchy (as shown earlier). Each subclass application objectfor a domain object whosedisplay was 

would return an instance of the widget appropriate for so simple that it did not need a separate application 

itself. Thus visualWidget is another example of the Factory object. ENVY extensions demonstrated that separate 

Method pattern, a more accurate example, si nee subclass- objects are not the only way to separate independent 

es override the su peri mpiementer. I ayers of code. 

Adding an application layer method like visualWidget I hope this successfully illustrates these techniques and 

into a domain layer object like Answer is certainly unusu- shows how they may be used to solve real-world prob- 

al, but not necessarily wrong. It was, after all, a single lems. I feel it is important not only that we document 

method, not a whole suite of behaviors that could easily these techniques as reusable design patterns and pattern 
become indistinguishable and inseparable from the languages, but also that we show how they can be applied 
domain behavior. Furthermore, its behavior is likely to be in practice to help develop better-quality software. I hope 
appropriate for any application layer that might be built this experience report will prove useful to you. Pleasefeel 
on this domain, so there is little need to be able to swap free to contact me at woolf@acm.org if you have any 
one application object in for another. (tastefully phrased) questions or comments. H 

9 


January 1996 




CLASS-LIKE HIERARCHY 


References 

1. Beck, K. Death to case statements, part 2, T he Smalltalk 
Report 3(4), 1994. 

2. Auer, K. Reusability through self-encapsulation, Coplien,J.O. 
and D.C. Schmidt, Eds., Pattern Languages of Program 
Design, Addison-Wesley, Reading, MA, 1995. 

3. Gamma, E., R. Helm, R.Johnson, andj. Vlissides. Design 

Patterns: Elements of Reusable Object-Oriented Software, 

Addison-Wesley, Reading, M A, 1995. 

4. Hendley, G. The NoWorker pattern, available from the author at 
gh en d I ey@kscca ry.com 

5. Carlini, G. Type and implementation, availablefrom the author 
atgiuliano@filenet.com 

6. Beck, K. Inheritance:The rest of thestory, The Smalltalk 
Report 3(1), 1993. 

7. Beck, K. Clean code: Pipe dream or state of mind? The 
Smalltalk Report 4(8):20-22,1995. 

8. Woolf, B. M aking M VC code more reusable, The Smalltalk 
Report 4(4): 15-18,1995. 


Bobby Woolf isa Member ofTechnical Staff at Knowledge Systems 
Corp.in Cary, North Carolina. He is actively engaged in the patterns 
movement that is seeking to document common software de¬ 
velopment techniques.Comments are welcome at woolf@acm.org. 



The Smalltalk Report 






